-
Notifications
You must be signed in to change notification settings - Fork 325
Adds methods for setting TagMap.Entry directly on AgentSpan/DDSpan #10472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
EntryIterator and EntryChangeIterator are arguably redundant
Fixed bug TagValueConversions.toBoolean Could cause LegacyTagMap.EntryReader to produce incorrect answers to some queries For simplicity, now treating Byte and Short as Integer. That will make calling code doing primitive handling simpler. Fleshing out tests -- more tests to come
Coverage for byte, short, float, and double
Adding methods to AgentSpan / DDSpan that take TagMap.Entry/Reader objects directly This will enable TagMap.Entry reuse which can reduce memory allocation/GC pressure
Methods are intended to be used to create TagMap.Entry objects for repeatedly used values Overloads are provided for all the supported types to be easier for developers not familiar with TagMap internals. Internally, TagMap still uses the more explicit new<X>Entry methods.
Removing statics that were previously moved to TagValueConversions
- tests exposed missing TagMap.Entry.create for boolean - added explanatory strings to some asserts
dd-trace-core/src/main/java/datadog/trace/core/DDSpanContext.java
Outdated
Show resolved
Hide resolved
internal-api/src/test/java/datadog/trace/api/TagMapEntryTest.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Alexey Kuznetsov <alexey.kuznetsov@datadoghq.com>
Using DisplayName to improve readability instead of separating prefix / suffix with underscore
| } | ||
|
|
||
| public void setTag(TagMap.EntryReader entry) { | ||
| if (entry == null) return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want a similar check in setMetric?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point.
I cannot quite decide how I want to handle null here.
In general, I'm not a fan of defensive checks everywhere, but letting nulls flow through does make sense in a lot of cases.
I guess I'll add the same check in setMetric.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've decided to go a step further and have TagMap.Entry.create handle null values by returning null.
That will provide the nice property of allowing null to flow through TagMap.Entry.create and into AgentSpan.setTag / setMetric.
That will simplify the Git related changes that build on this.
- setMetric not guards against null - TagMap.create now allows null - and returns null in response The intention is to let null values benignly flow through TagMap.Entry.create into AgentSpan.setTag / setMetric
Fixing oversight of creating newAnyEntry rather newObjectEntry in create(tag, CharSequence)
…aDog/dd-trace-java into dougqh/fdirect-apis-for-tagmap-entry
What Does This Do
Adds methods to TagMap.Entry to create entries directly
Adds methods to AgentSpan / DDSpan to set TagMap.Entry(Reader) directly
Motivation
The intention is to enable reuse of TagMap.Entry objects to further reduce allocation
Those improvements have been prototyped and shown to be beneficial, but will be done in separate pull requests
I'd originally hoped to make reuse of TagMap.Entry-s hidden from instrumentation by adding in caches behind the scenes, but that approach didn't pan out. The caches were beneficial when memory was scarce, but harmful when memory is plentiful.
So for now, the simplest approach is to expose APIs, so TagMap.Entry-s can be used directly in the key places where doing so is beneficial. Examples include static meta information, git related tags, db connection info, etc
Additional Notes
It will probably also make sense to extend these changes to TraceSegment; however, TagMap isn't currently visible to TraceSegment at build time. To keep this pull request simple, changing TraceSegment is left to another pull request
Contributor Checklist
type:and (comp:orinst:) labels in addition to any useful labelsclose,fixor any linking keywords when referencing an issue.Use
solvesinstead, and assign the PR milestone to the issueJira ticket: [PROJ-IDENT]